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OBJECT TRANSFER CONTROL IN A COMMUNICATIONS NETWORK 



BACKGROUND OF THE INVENTION 



1. Technical Field 

The invention generally relates to the field of communications networks and more particu- 
larly to an object transfer from a first network component via an intermediate component 
to a second network component, the second network component being remote from the 
first network component. 

2. Description of the Prior Art 

The transfer of information over modern communications networks like the public Inter- 
net or internal networks is based on specific transfer protocols. The World Wide Web for 
example, which constitutes a major aspect of the Internet, uses the Hyper Text Transfer 
Protocol (HTTP) for exchanging files comprising text. Images, sound, video, and other 
contents. 

Any WWW server contains. In addition to the files it can serve, an HTTP component that 
is designed to wait for HTTP requests and to handle them when they an-ive. A WWW 
browser can be considered as an HTTP client that is configured to send HTTP requests to 
WWW servers. Whenever a user of the browser enters a file request by either "opening" a 
WWW file (by typing in a Uniform Resource Locator (URL)) or by clicking on a hyper text 
link, the browser builds a corresponding HTTP request for the file and sends it to the des- 
tination address. The HTTP component in the destination server receives the HTTP re- 
quest and returns the requested file. 

The requested file may be constituted by a Hyper Text Mark up Language (HTML) page 
that Includes HTML code. When the browser receives the HTML page from the server and 
detects that the HTML code, which can be considered as an object Itself, includes further 
objects such as (background) images, sounds, scripts or HTML frames, the browser Issues 
further HTTP requests to the server in order to fetch the further objects which are in- 
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duded In the HTML code. Upon receipt of the ftjfther HTTP requests, the server sends 
HTTP responses including the requested objects l\ke images to the browser. As becomes 
apparent from Rg. 1, the HTTP responses are sent from the server to the browser run- 
ning on the client in the same order as the browser has issued the HTTP requests. 

The order in which any additional objects included in the HTML code of the HTML page 
are requested by the browser usually depends on how the HTML page was written. For 
example an object that is included at the beginning of the HTML code is not necessarily 
displayed at the top of the HTML page because features such as tables, layers and frames 
allow the HTML author to use complex layouts. In addition, the order in which a browser 
issues HTTP requests depends also on internal browser algorithms. For example some 
browsers use complex heuristics for generating the HTTP requests by starting with re- 
questing the first four objects as they appear in the HTML code of the page. After the first 
four objects have been requested, ever/ second object starting from the top of the area 
that is currently visible to the user is requested, then every fourth object and so on. Other 
browsers use a simpler algorithm that requests the objects one by one as they appear In 
the HTML code. From the above it becomes apparent that it is usually difficult to predict 
the order in which HTTP requests for objects referred to In an HTML code are generated. 

Moreover, it is difficult to predict the order in which requested objects are received by the 
browser. Although the current HTTP standard (HTTP/1.1) requires that on each Transfer 
Control Protocol (TCP) connection the HTTP responses are sent from the server to the 
browser in the same order as the HTTP requests are received by the server, the order in 
which HTTP responses are received becomes unpredictable as soon as more than one 
connection is opened to the server. The reason therefore is the fact that due to varying 
networi< conditions and different request processing times, some connections may trans- 
fer HTTP responses faster than others. 

There is a need for a method and a device that enable an improved transfer of objects 
from a first network component to a second networl< component which Is remote from 
the first network component. 

SUMMARY OF THE INVENTION 

According to one aspect of the invention this need is satisfied by a method of controlling 
In a communications networic an object transfer from a first component via an intermedi- 
ate (hardware or software) component to a second component which is remote from the 
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first component, wherein the object transfer is based on a plurality of object requests 
relating to objects refen-ed to in one or more codes to be processed by the second or 
another component of the communications network and wherein the intermediate com- 
ponent performs the steps of sending an object request to the first component, receiving 

5 the requested object fi-om the first component, at least one of assessing and updating a 
priority of the requested object, wherein an Initial priority has been assigned to the re- 
quested object on the basis of an analysis of at least one of the object request and the 
code that refers to the requested object, and, in dependence of the priority of the re- 
quested object, delaying the requested object or forwarding the requested object to the 

10 second component. An object may itself comprise code portions referring to one or more 
further objects. Furthermore, a code may Itself form a (e.g. previously requested) object. 

By intentionally delaying the object transfer based on an assigned priority, the overall 
transfer of objects is improved from a user's point of view (even if the total amount of 

15 data to be transferred is not decreased) because important objects are transferred pref- 
erentially. Furthermore, by implementing appropriate priority assignment schemes the 
object transfer from the first networi< component to the second networic component be- 
comes more predictable. For example objects being of higher significance to the user may 
be assigned a higher priority and may thus be preferentially transferred to the second 

20 component. On the other hand, objects being of lesser significance may be delayed. In 
the extreme case an object having a low significance may be delayed to such an extent 
that it Is not transferred to the second component at all. This allows to control the order 
in which objects are received by the second component. 

25 The assignment of absolute or relative priorities to objects (or classes of objects) may be 
performed dynamically. Once a priority has initially been assigned, this priority may be 
assessed with respect to specific absolute values like thresholds or with respect to priori- 
ties of other objects. Based on the assessment it can be decided whether or not an object 
is to be delayed. Prior to the assessment a priority Initially assigned to an object may be 

30 evaluated anew with the purpose of determining whether the initial priority has to be up- 
dated. 

The intermediate component may be operated to re-order objects received from the first 
component. The delaying of objects Is thus preferably performed such that the order In 
35 which the intermediate component receives the objects from the first component differs 
from the order In which the objects are forwarded to the second component. The re- 
ordering may be based on the priorities of tiie objects to be transferred. During tiie re- 
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ordering there might arise the situation that due to the delay of some objects the transfer 
of other objects Is actually accelerated. 

The object request that is sent to the first component may be generated by the interme- 
5 diate component. When the requested object is received by the intermediate component, 
it "pushes" It to the second component without having received an explicit object request 
from the second component. Alternatively, the object request may be generated by the 
second component and sent to the intermediate component. Upon receipt of the object 
request from the second component. It may be processed by the Intermediate component 
10 and forwarded to the first component. 

When the intermediate component receives the requested object from the first compo- 
nent, the received object may either be delayed or directly forwarded to the second com- 
ponent. There exist various possibilities how the requested object that is received by the 

15 intermediate component can be delayed. Delaying of the requested object can for exam- 
ple include at least one of instructing the second component to repeat the object request, 
suspending a connection to the second network component via which the requested ob- 
ject is to be forwarded, and informing the second component that the requested object 
will automatically (e.g. without any further object request from the second component) 

20 be forwarded to the second component at a later point in time. 

If delaying of the requested object Includes Instructing the second component to repeat 
the object request, the intermediate component may perform the steps of assigning a 
specific attribute to the object to be delayed, informing the second component of the at- 

25 tribute, receiving a reference to the attribute (e.g. the attribute Itself or an unambiguous 
reference derived from the attribute) from the second component, and, upon receipt of 
the reference to the attribute, sending the delayed object to the second component or 
further delaying the delayed object. The decision whether a delayed object Is to be sent 
to the second component or delayed further may be based on the newly assessed relative 

30 priority of the repeatedly requested object. 

The attribute can be considered as a common denominator which enables the intermedi- 
ate component and the second component to negotiate about the transfer of the object 
to which the attribute has been assigned. Usually, the form of the attribute will depend 
35 on the characteristics of the transfer protocol that is used for the object fransfer. In the 
case of HTTP for example, the attribute may be constituted by a virtual URL created by 
the Intermediate component. It should be noted that the attribute-based delay scheme of 
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instructing the second component to repeat the object request can generally be used to 
delay objects and does not necessarily require that priorities have been assigned to the 
objects to be transferred. 

5 In the attribute-based delay scheme the object may be send from the intermediate com- 
ponent to the second component in response to an object request received from the sec- 
ond component or in accordance with a pushing scheme, i.e. independently of such an 
object request from the second component. If the delay scheme is based on an object 
request received from the second component, the second component may be informed 

10 about the attribute in context with an instruction to repeat the object request. In such a 
case the reference to the attribute may be received by the intermediate component in 
context with a repeated object request from the second component. 

The objects to be transferred to the second component may be fonwarded to the second 
15 component via a single or via a plurality of connections between the intermediate compo- 
nent and the second component. In such a multiple connections scenario selected ones of 
the connections to the second component may be suspended dependent upon the (initial 
or updated) priorities of the requested objects that are to be forwarded via the selected 
ones of the connections to the second component. The Intermediate component may thus 
20 suspend one or more connections so that objects having a high priority can make use of 
the additional bandwidth that is released on the link between the Intermediate component 
and the second component. In order not to waste available bandwidth the Intermediate 
component Is preferably configured such that It ensures that a link formed by two or 
more connections is fully used before suspending one or more connections thereof. 

25 There exist various techniques for suspending a connection. For example transmission 
over the connection could be blocked for a specific period of time while leaving the con- 
nection as such open (intermediate state = open). Alternatively, tiie connection could be 
closed (Intermediate state = closed) while saving the state of the connection. In such a 
case the connection may be reopened at a later point In time In the same state In which it 

30 was closed. According to a third possibility, the connection may be completely closed 

without saving any information about the state of the connection. In any case the second 
component can be Informed that the one or more objects to be transmitted via tine closed 
connection will be sent later, either in response to or independentiy from a (repeated) 
object request. 

35 Instead of or in addition to suspending individual connections, the object transfer may 

also be delayed by a priority based adjustment of the transfer speed. To that end, a spe- 
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dfic share of processing capabilities may be dynamically allocated to each object or each 
connecbon. In the case of multiple connections, all connections or at least some connec- 
tions get a share of the CPU time, i.e. a share of the network bandwidth. The share of 
processing capabilities allocated to a specific connection may be changed (e.g. decreased 
constantly) while one or more objects are transfen-ed via the respective connection. 

It has been mentioned above that the object transfer is based on a plurality of object 
requests relating to objects referred to In one or more codes. According to a first variant 
of the invention a code is readily available to at least one of the second and the interme- 
diate component. According to a second variant of the Invention the code has yet to be 
loaded by either one of the second and the intermediate component. In the latter case 
the intennediate component may send a code request that has been generated by the 
second component or by the Intermediate component to the first component or a third 
component that is different from the first component. When the requested code is re- 
ceived fi-om the first or the third component, it may be analyzed by the intermediate 
component with respect to references to objects comprised within the code. Any refer- 
ences to objects contained in the code may then be assessed with the purpose of assign- 
ing (initial) priorities to the objects refen-ed to in the received code. The code received 
ft-om the first or the third component may eventually be fonwarded by the intermediate 
component to the second component. 

Upon receipt of a response fi-om the first component the requested object contained in 
the response may be evaluated with respect to the received object's priority. For example 
at least one of the object size, the object content and a header of the response may be 
analyzed to that end. It can then be determined whether or not an initial priority of a re- 
ceived object has to be updated. 

Preferably, at least some infomiation about each object or each class of objects is stored 
for example by the intermediate component. The stored information may comprise prior- 
ity information for individual objects or a classes of objects, preferably, in the form of a 
priority list. This priority list may be repeatedly assessed. Such an assessment can relate 
to at least one of updating priority information and deleting objects or classes of objects 
from the priority list. 

The invention may be implemented as a hardware solution or as a software solution. In 
the case of a software solution the Invention may be realized in tiie form of a computer 
program product comprising program code portions for perf^ormlng the individual steps of 
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the invention. The computer program product may be stored on a computer readable 
recording medium. 

According Xo a preferred embodiment of the invention the intemiediate component is Im- 
plemented as a proxy component in the form of a piece of software running on the first 
or the second component of the communications networl<. If the invention is implemented 
as a hardware solution, the intemnediate component may be constituted by a separate 
piece of hardware like a proxy server arranged between the first and the second compo- 
nent in the communications network. The intermediate component may Include one or 
more appropriately configured communication interfaces for communicating with at least 
the first and tiie second component of the communications network as well as a unit for 
performing the processing in context with delaying of objects. 

In tiie communications network there exists a first link between the intennediate compo- 
nent and the first component and a second link between tiie Intermediate component and 
tiie second component. Preferably, the first link and tiie second link have different ti^ns- 
fer rates. For example a fest link may be provided between the intermediate component 
and the first component and a comparatively slower link may be provided between the 
intermediate component and the second component. This sitijation is usually given when 
the first component is a network sen/er, the second component is a network client and 
the intermediate component is located In tiie vicinity of (in terms of network links) or on 
the network server. However, the intermediate component could also be located dose to 
(in temis of network links) or on tiie network client. In such a case tiie link between the 
intermediate component and the second component (the network client) has a much 
higher capacity and lower latency than tiie link between the intermediate component and 
the first component (the network server). 

It should be noted tiiat the Invention is not restricted to tiie case that the first component 
acts as network server and the second component acts as network client. In particular, 
the Intennediate component could also be used to improve tiie object transfer between 
two network clients or two network servers. 

According to an especially preferred embodiment of the invention tiie Intemiediate com- 
ponent is part of a wireless communications network like a GSM, GPRS, etc. cellular net- 
work. In such a network the second component may be constituted by a mobile temiinal. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

Further aspects and advantages of the Invention will become apparent upon reading the 
following detailed description of preferred embodiments of the invention and upon refer- 
ence to the drawings, in which: 

Fig. 1 is a schematic diagram illustrating a transfer of objects between a network server 
and a network client In accordance with HTTP; 

Rg. 2 is a block diagram of a network system comprising an intermediate component in 
the form of a HTTP proxy server according to the invention; 

Rg. 3 is a block diagram of the HTTP proxy server of Rg. 2; 

Rg. 4 is a schematic diagram depicting a redirection-based object delay In the network 
system depicted in Rg. 2; 

Rg. 5 is a flow chart reflecting the steps preceding an object delay; 

Rg. 6 Is a flow chart depicting tiie decisions involved In an object ti^nsfer according to 
the Invention; and 

Rg. 7 is a block diagram depicting a proxy component according to the invention located 
on a network client. 

DESCRIPTION OF A PREFERRED EMBODIMENT 

Although the present invention can be practiced in any communications network in which 
a request-based object transfer via an Intermediate component is performed, the follow- 
ing description of preferred embodiments Is exemplarily set fortii with respect to tiie 
transfer of HTML code In accordance with tiie HTTP protocol over the WWW. In principle, 
ti-ansfer protocols different from HTTP, like the wireless WAP fa^nsport: protocol or some 
Remote Procedure Call (RPC) mechanisms, and codes different from HTML, for example 
the WAP Markup-Language (WML) or any derivatives of the extensible Markup-Language 
(XML), could be utilized as well. Furthermore, although the following description mainly 
concerns an object fansfer from a server to a client, the object transfer could be per- 
formed between any two or more network components. 

In Rg. 2, a block diagram of a network system 10 according to the invention is depicted. 
As becomes apparent from Rg. 2, the network system 10 comprises a first component in 
the form of a server 20, an Intermediate component in the form of a HTTP proxy server 
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30 and a second component in the form of a client 40. The proxy server 30 is arranged In 
the network system 10 such tJiat it has a fast link 12 towards the server 20 and a com- 
paratively slower link 14 towards the client 40. Each link 12, 14 Is constituted by a plural- 
ity of TCP connections 50. Each TCP connection 50 is configured to allow the transfer of 
HTTP requests and HTTP responses between the server 20 and the dient 40. 

The proxy server 30 performs some traditional proxy functions like caching and filtering of 
objects. Additionally, the proxy server 30 is configured to artificially delay an object that is 
received ft-om the server 20 and that is to be forwarded to the dient 40. This is done by 
using a combination of temporary suspension of data transfer on some connections 50 
and HTTP redirection messages that force a browser mnning on the dient 40 to repeat an 
object requested after a certain period of time. By using these mechanisms the proxy 
server 30 re-orders the HTTP responses received from the server 20 in such a way that 
objects having a higher priority are delivered to the dient 40 first. For that purpose the 
proxy server 30 dynamically assigns priorities to the objects to be forwarded to the dient 
40. In order to ensure that delaying of the less important objects does not cause the link 
14 between the proxy server 30 and the dient 40 to become idle, the proxy server 30 
continuously or at least repeatedly monitors the traffic on this link 14. 

The construction of the proxy server 30 is depicted in more detail in Fig. 3. As becomes 
apparent from Fig. 3, the proxy server 30 comprises a communications interiace 32 cou- 
pled between the first link 12 to tiie server 20 and the second link 14 to tiie dient 40. The 
communications interiiace 32 is configured such that it enables tine sending of object re- 
quests to and the receipt of tiie requested objects ftom tiie server 20. A processing unit 
34 of the proxy server 30 communicates with tiie communications interface 32. The proc- 
essing unit 34 allows to assess and/or adapt tiie priority of any object received via ttie 
first link 12 ftom the server 20. Additionally, the processing unit 34 allows to assign an 
initial priority to a requested object on tiie basis of an analysis of at least one of tiie ob- 
ject request and the code that refers to the requested object. Possible assignment 
schemes will be discussed later in more detail. 

In dependence of the initial or updated priority of an requested object tiie processing unit 
34 controls the communications interf^ace 32 such tiiat a requested object received from 
the server 20 Is eitiier delayed or forwarded via the second link 14 to tiie dient 40. If a 
requested object received from ttie server 20 Is to be delayed, it is temporarily stored in a 
bufffer 36 that can be accessed by both the communications interface 32 and the process- 
ing unit 34. Alternatively or In addition, ttie buffer 36 may be implemented as a software 
or hardware component of the processing unit 34. 
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Besides the tasks outlined above, the processing unit 34 is additionally configured such 
that it allows to assign a specific attribute to an object which is to be delayed (an exem- 
plary format of this attribute will be discussed later in more detail). The processing unit 
34 enables to control the communications interface 32 such that the communications in- 

5 tertBce 32 informs the client 40 about this attribute. If the communications interface 32 
receives a reference to the attribute fixim the client 40, the processing unit 34 evaluates 
this reference and controls the communications interface 32 such that the delayed object 
to which this attribute has previously been assigned and which is currently stored in the 
buffer 36 is either sent to the client 40 or further delayed. A further delay of the object 

10 stored in the buffer 36 may become necessary if objects of a higher priority have to be 
fonwaixled to the client 40 first. 

In the following, a preferred operational mode of the network system 10 shown in Rg. 2 
will exemplarily be described. 

When a user enters a URL, dicks on a link or follows a bookmaric, the browser running on 
15 the client 40 issues a HTTP request for the con-esponding HTML page including HTML 

code. The HTTP request issued by the browser is received by the proxy server 30 via the 
link 14 and forwarded via the link 12 to the destination sen/er 20. The server 20 replies 
by sending the HTML code for the requested page to the proxy server 30, which analyzes 
the HTML code received from the sen/er 20 to assign an initial priority to any kind of ob- 
20 jects like links, frames, scripts, images, etc. referred to in the HTML code (first analysis 
phase). 

Independently fi-om this analysis of the HTML code, tiie proxy server 30 fomards the 
HTML code via the link 14 to the client 40. When the browser running on the client 40 
receives tiie HTML page including the HTML code it processes tiie HTML code. If the 

25 browser detects that the HTML code includes further objects, it issues fijrther HTTP re- 
quests for the objects referred to in the HTML code. These HTTP requests for further ob- 
jects are received and evaluated by the proxy seiver 30. To most of tiie requested ob- 
jects an initial priority will have been assigned already during tiie proxy server's 30 previ- 
ous analysis of tiie HTML code that it has fonwarded to the server 40. However, in tills 

30 second analysis phase the proxy server 30 either assigns initial priorities to ttiose objects 
to which a priority has not yet been assigned or updates tiie priority of such objects to 
which an initial priority has already been assigned. The priority is updated on tiie basis of 
additional Information available In the HTTP request received from tiie client 40. 
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The proxy server 30 forwards any HTTP requests for additional objects received from the 
client 40 to the server 20. TTie server 20 replies by sending the requested objects to the 
proxy server 30. The proxy server 30 analyzes the HTTP responses (Including the re- 
quested objects) from the server 20 In a third analysis phase and updates - if necessary - 
the priorities of the objects comprised in the HTTP response. Additionally, the proxy 
server 30 assesses the relative priority of any received object with respect to the priority 
of previously received objects that are still stored in the buffer 36 (see Rg. 3) and the 
priorities of objects that are expected soon. Information regarding the objects that will be 
received soon from the server 20 can be derived from the HTML code that has previously 
been forwarded to the client 40 or from HTTP requests from the client 40 for which the 
corresponding objects have not yet been received from the server 20. Alternatively or 
additionally, the proxy server 30 may be configured such that it compares a priority of an 
object that has just been received from the server 40 with an absolute value like a priority 
threshold. 

Based on the evaluation of an object's absolute and/or relative priority and the current 
and/or predicted traffic on the link 14, the proxy server 30 decides ff this object is to be 
delayed, e.g. if this object Is to be temporarily stored In the buffer 36 or if the corre- 
sponding HTTP request is not yet to be forwarded to the server 20, or if the object is to 
be immediately fonwarded to the client 40. 

The intentional delay of individual objects improves the overall object transfer from a 
user's point of view. It is for example well known that the relative importance of the vari- 
ous objects included In a web page varies greatly: An image that is used to build a 
graphical menu may be essential for the navigation of a site, while a background Image 
merely makes the page look nicer. The Invention can thus be employed to provide the 
user with the more important Infomiation first. As soon as there Is enough Information of 
a web page displayed on the user's screen, the user can decide to dick on a link and re- 
quest another web page without having to wait for the remaining (less important) parts 
of the previous web page that Is still being transferred. As a result, the user is no longer 
forced to wait until some uninteresting objects are fransferred before being able to see 
the important ones. This Is especially useful in conjunction with the mobile Internet, 
which Is usually slower and more expensive than the fixed Internet. 

Assignment and Adjustment of Priorities 

As has become apparent from the above, the proxy server 30 can assign or adjust the 
priority of an object to be sent to the client 20 during three different phases, namely 
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when a reference to that object is found In an HTML code (I.e. In a previous object) that 
is to be forwarded to the client 40, when a HTTP request relating to that object is issued 
by the browser running on the dient 40, or when the corresponding HTTP response con- 
taining the requested object is received from the server 20. 

In the following, various schemes for assigning or updating priorities during each of these 
three phases are exemplarily described. During any of the three phases a priority list that 
contains priority information for individual objects or classes of objects is either generated 
or updated. In the priority list, the individual objects or classes of objects are ordered 
with respect to Increasing or decreasing priority. TTie order of the objects in the priority 
list can thus be considered as priority information. However, additional priority informa- 
tion like absolute or relative priority values (numbers) may alternatively or additionally be 
part of the priority list. 

The exact priority assigned to specific objects or classes of objects Is implementation- 
dependent and In the exemplary embodiment configurable by the operator of the proxy 
server 30 or a user of the browser running on the client 40. For example in order to allow 
the operator of the proxy server 20 to have more control over the priority of some ob- 
jects, there could be one or several lists of URLs (using pattern matching) that allow the 
operator to increase or decrease the priority of the objects appearing on those lists. For 
example an operator could decide to increase or decrease priority of all images 
downloaded from an advert:ising company. The same possibilities may be made available 
to the user. For example the user could send his preferences to the proxy server 30. This 
can be done by a specific software running on the dient 40 or by using designated web 
pages provided dlrectiy by the proxy server 30 and allowing the user to set his prefer- 
ences. 

In the first analyzing phase the proxy server 30 can assign an Initial priority to an object 
by analyzing an HTI^IL code that has been requested by the client 40 from the server 20. 
In particular, references to objects referred to in the HTML code may be assessed to that 
end. In this way a priority list may be generated that lists individual objects which are 
referred to in the HTML code In the following order (objects of highest priority are men- 
tioned first): 

linl<s to other pages 



frames 
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inlined images (if the II^G tag includes width and height Information, this infonna- 
tion can be used to refine the priorit/ of images depending on the expected di- 
mensions so that smaller images get a higher priority than larger ones) 

style sheets 

scripts (JavaScript, VBScript, etc.), embedded objects and applets 

bacicground Image (page background, table background, style sheet, etc.) 

any object that was already sent to the client 40 gets the lowest priority 

In addition the priority of a specific object can be lowered If the object is not located on 
the same server 20 or on the same domain as the current HTML page. 

A further possibility to assign or adjust the priority of an object occurs when a request for 
that object is issued by tine browser and received by the proxy server 30. In such a case 
the HTTP request can be analyzed by the proxy server 30 In an URL context (second 
analysis phase). Since initial priorities have already been assigned during analysis of the 
HTI^L code that led to tiiat HTTP request, analysis of tiie HTTP request will usually result 
in an adjustment of the Initial priority. However, In some cases Initial priorities may be 
assigned also (see above). 

The adjustment or assignment of initial priorities in the second analysis phase can be per- 
formed in dependence on additional information available for example in the header of 
the HTTP request. One or more of the following rules for updating the priorities may be 
implemented: 

The analysis leads to the result that the browser has already requested the same 
object once. Such an object Is preferably assigned a very high priority In order to 
avoid Infinite loops caused by browsers that are not fully compliant to HTTP/1.1 
and ignore the Retry-After header (this header will be discussed below in more de- 
tail). 

The object does not have a priority yet, but the file extension looks like HTML 
C'.HTML'V'.HTM") or XML (".XML") or looks like a directory index (ends"/")- Such a 
priority assignment ensures that a HTML page requested from the bookmarks or 
typed in directiy will be requested with a high priority. 
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The browser makes a conditional HTTP request for an object, using If-modified- 
since or similar conditions. This indicates that the browser has probably cached a 
copy of the object. The reply is expected to be small if the cached copy is still 
valid (HTTP reply code "304 not modified"). 

The URL of the requested object was found while pgrsing a previous HTI^IL page. 

Any object that was not inserted in the list while parsing the HTML tags of a pre- 
vious page was probably requested indirectly by a script and should get a lower 
priority than most of the other requested objects. 

In the third analysis phase, the adjustment of object priorities is based on an analysis of 
the HTTP response from the server 20. The adjustment of the priorities in the third analy- 
sis phase (as well as in the second analysis phase mentioned above) can be calculated as 
a weighted sum of several criteria. The weights may be configurable by the operator of 
the proxy server 30 or the user of the browser running on the client 40. 

In the tiiird analysis phase, all objects will usually have a priority assigned to them. How- 
ever, this priority can be updated before sending the requested objects to the client 40. 
To adjust the priorities, the headers and contents of the HTTP responses received from 
the server 20 may be assessed. The priorities may then be adjusted in accordance with 
one or more of the following rules: 

Assessment of the reply code: tiie relative priority of the HTTP responses depends 
on the firet digit of the reply code. Error codes (4xx, 5xx) should have a higher 
priority than normal replies (2xx). 

Assessment of the content type: a HTML code should have a higher priority than 
any image. 

Assessment of the objects size (derived from the content-lengtii if specified in the 
headers, or from the total size if the object is already cached): smaller objects 
should have a slightly higher priority than larger ones. 

Analysis of the content: for example animated images can be assigned a lower 
priority tiian static images. The analysis of tiie content can also form the basis for 
estimating the size of the object if this information is not available in the HTTP 
header and the object has not yet been cached. 
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If the reply code is a permanent or temporary redirection (3xx) specifying a new 
location for the requested object;, then this new location gets the same priority as 
the original object. 

In the three analysis phases described above tfie proxy server 30 sets and updates the 
priorities of tiie objects that are to be transferred to the client 40. The proxy serv^er 30 
thus keeps some information about each object like the object's URL, priority, time of last 
request and, if required, some further parameters. However, this information can not be 
kept forever since othenwise the proxy server 30 would run out of memory. Moreover, if 
an object to which a high priority has been assigned is never requested, action is prefera- 
bly taken so that it does not prevent other objects from being transferred. 

For these reasons a routine Is Implemented ttiat ensures that Information tiiat is no longer 
up to date or that Is no longer required Is deleted. To that end one or more of tfie follow- 
ing mechanisms may be used: 

Any object that is successfully transferred to the client is mariced as having been 
sent or is moved to a separate list of objects that have been sent to tiie client 40. 

A maximum size for one or more lists containing relevant information is set and 
configured such that older objects or objects witii the lowest priority expire first. 

Whenever the client resets a TCP connection before the object Is fully transferred 
(meaning that the user has stopped the download and may have selected anotiier 
page), clear the information of objects to be sent. 

As an alternative to tine previous solution, keep cross-references for each object In 
order to associate each HTML page with the objects that it contains and vice 
versa. When the client 40 resets a TCP connection, remove only tiie objects that 
are Included in the same HTML page. 

The priority of all objects can be decreased after a specified amount of time or 
after some number of HTTP requests or HTTP responses have been processed. 

Reordering of Objects 

In the previous chapter the generation of a priority list for tiie requested objects to be 
ta-ansferred to the client 40 as well as possible updating mechanisms for tiiis priority list 
have been described. Usually, the requested objects will be received by the proxy server 
30 ftx)m the server 20 in an order ttiat Is difl^erent from the order Indicated in tiie priority 
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list. Consequentiy, the proxy server 30 has to reorder the objects received from the 
server 20 in such a manner that they are forwarded from the proxy server 30 to the client 
40 in an order which reflects the order in the priority list as closely as possible. The proxy 
server 30 reorders the objects received fix)m the server 20 by intentionally delaying ob- 
jects having a lower priority and by forwarding objects having a higher priority without 
any substantial delay to the client 40. 

The proxy server 30 uses a combination of different delay mechanisms to reorder the 
objects received from the server 20. In the following, two of these delay mechanisms, 
namely suspension of TCP connections on the one hand and HTTP redirections on the 
other hand, will exemplarily be described in more detail 

Suspension of TCP connections 

As becomes apparent from Rg. 2, the link 14 between the proxy server 30 and the client 
40 is constituted by a plurality of TCP connections 50. Dependent upon the priorities of 
the requested objects that are to be forwarded via individual ones of the connections 50, 
one or more of the connections 50 that are Intended for the transfer of objects having a 
low priority are suspended. This suspension of individual connections releases some 
bandwidth on the link 14 that is now available for preferentially ti^nsfening objects hav- 
ing a higher priority. Consequentiy, objects having a higher priority will be delivered be- 
fore objects ha^nng a lower priority. 

The suspension of an Individual connection 50 is performed such that the connection 50 is 
left open without transferring objects for a certain period of time. Alternatively, suspen- 
sion of a connection 50 could be effected by closing the connection 50, either with our 
without saving ttie state of the connection 50 prior to its suspension. When the state of 
the suspended connection 50 is saved, it can be opened at a later point in time in tiie 
same state as it has been suspended (i.e. closed). 

Suspension of a connection 50 has ihe advantage that no extra data has to be sent via 
the link 14. Preferably, a connection 50 is suspended only if the released bandwidth can 
be fully used by some other connections 50 for the transfer of objects having a high prior- 
ity. 
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The proxy server 30 is thus configured such that It checks that the link 14 is fully used 
before suspending a connection 50 in order not to waste available bandwidth. A possible 
routine for predicting if the link 14 is or will be partially idle includes comparing the aver- 
age throughput (over the last N seconds) of all connections 50 going to the client 40 with 
the amount of data that is cun^ntly cached or buffered in the buffer 36 of the proxy 
server 30 (see Rg. 3) and is ready to be sent. Other and in particular simpler techniques 
for estimating the utilization of the link 14 could be implemented as well, especially if the 
available bandwidth on the link 14 is known by other means. 



HTTP redirections 



If the proxy server 30 expects that objects having a high priority will soon have to be 
transferred to the client 14 (e.g. because links to these objects have previously been de- 
tected by the proxy server 30 while forwarding the HTML code of a HTML page to the 
client 40), and suspension of a connection 50 would waste some bandwidth because 
there is currently nothing else to transfer on the other connections 50, then the proxy 
server 30 may utilize another delay scheme. A possible delay scheme that is applicable in 
such a case includes instructing tiie client 40 to repeat an object request at a later point 
in time. 

Although HTTP specifies that any HTTP responses must be sent to the dient 40 in the 
same order as tiie browser running on the client 40 has Issued tiie HTTP requests, it is 
possible to Instruct the browser to retry a HTTP request later. This can be done by send- 
ing a HTTP response witii the status code "302" to tiie client 40, together with the header 
field "Retry-After". This header field tells the client 40 to retry his HTTP request after a 
specified amount of time. In response to tiie receipt of the statijs code "302" (possibly 
including the "Retry-Aft:er" header field), current browsers re-schedule tiie HTTP request 
after all pending HTTP requests have been processed. 

The status code "302" as specified in the HTTP standard 1.1 tells the browser that a 
given object can be found (temporarily) at a location that is different from the one that 
was requested. The HTTP response sent to the client 40 includes tiie new location of tiie 
object. This mechanism is used to implement tiie delay scheme according to the inven- 
tion. 
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According to the invention the proxy server 30 generates an attribute in the form of a 
new (virtual) URL for the object to be delayed. The proxy server 30 then instructs the 
browser running on the client 40 to try the HTTP request again, using this temporary at- 
tribute (i.e. URL) as the new location of the object. The browser is thus Instructed to re- 
schedule the HTTP request at a later point in time. When the browser repeats Its HTTP 
request (including the temporary attribute, I.e. the virtual URL), the proxy server 30 con- 
verts the attribute to the original URL and forwards the HTTP request to the server 20. 
Alternatively, the original HTTP request could have been forwarded to the server 20 after 
receipt thereof by the proxy server 30. In such a case the HTTP response received from 
the server 20 is temporarily stored by the proxy server 30 until it receives the repeated 
HTTP request from the client 40. 

In the following, the inventive delay mechanism discussed above will exemplarily be de- 
scribed in more detail witii reference to Figs. 4 and 5. It will be assumed that the HTTP 
request received by the proxy server 30 from tiie client 40 relates to an object tiiat is 
considered by the proxy server 30 to be of a low priority. 

In a first step 402 of Rg. 4, the proxy server 30 receives a HTTP request from the client 
40 via the link 14. In the exemplary case of HTTP this first request from the client could 
have the following format: 

GET http://example.com/some/image.png HTTP/1.1 
Host: example.com 

User-Agent: Mozilla/5.0 (Xll; Linux i686; en-US; rv: 0.9.9) 

Gecko/20020311 

Connection: close 

In response to the HTTP request received In step 402 from the client 40, the proxy server 
30 redirects the client 40 in step 404 to a new (virtual) location and Insbucts tiie client 40 
to wait for a certain period of time (delay) before retrying tiie HTTP request. The redirec- 
tion message fi^m the proxy server 30 on tiie basis of tiie status code "302" as specified 
In the HTTP standard 1.1 can have tiie following fonfnat: 
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HTTP/1.1 302 Found 

Date: Thu, 21 Mar 2002 15:12:47 

Server : PrioTest/0 . 9 

Location: http//example . com/some/ () image (0001) .png 
Retry-After: 5 
Connection: close 
Transfer-Encoding: chunked 

Content-Type: text/html; charset=iso-8859-l 
(some human-readable text follows) 

The proxy server 30 can now request the object from the server 20 at any time after re- 
ceipt of the initial HTTP request from the client 40 (step 402) and the time at which it 
decides to deliver the object to the client 40 (steps 406 and 408). 

After receipt of the above redirection message the client 40 waits for a period of time 
specified in the redirection message, i.e. five seconds (or until all other objects have been 
transferred). In step 412 the client 40 then repeats his HTTP request indicating the new 
(virtual) location as follows: 

GET http: //example- com/some/ 0 image (00001) -png HTTP/1.1 
Host : example . com 

User-Agent: Mozilla/5.0 (Xll; Linux 1686; en-US; rv:0.9.9) 

Gecko/20020311 

Connection: close 

Upon receipt of the repeated HTTP request from the client 40, the proxy server 30 de- 
cides whether to delay the requested object further (e.g. by suspending a connection 50 
or by a further redirection message) or whether to forward the delayed object to the cli- 
ent 40. If the proxy server 30 decides to forward the delayed object without any further 
delay, this can be done in the following format: 

HTTP/1.1 200 OK 

Date: Thu, 21 Mar 2002 15:12:50 
Server: Apache/1.3.23 (Unix) 
Content-Type : image/png 



wo 03/085924 PCT/EP02/03802 

-20- 



Content-Length : 1520 

(the contents of the image follow) 

5 Now, the decisions taken by the proxy server 30 in the course of the redirection routine 
discussed above with reference to Rg. 4 will be explained with reference to Rg. 5. 

In step 502 the proxy server 30 receives the HTTP request fi-om the client 40. In the fol- 
lowing step 504 the proxy server 30 determines whether the URL included In the HTTP 
10 request Is a modified URL, I.e. the result of a previous redirecbon. If this is the case, the 
proxy server 30 decodes the URL and restores the original location In step 506 and moves 
via node 508 to step 510. Otherwise the method directly moves from step 504 via node 
508 to step 510. 

15 In step 510 the proxy server 30 determines if the object requested by means of the HTTP 
request is already available, i.e. stored in the buffer 36 of the proxy server 30 (see Rg. 
3). If the object is not already cached, the proxy server 30 requests the object from the 
server 20 or marl<s it for later retrieval in step 514. From step 514 the method moves via 
node 512 to step 516. Step 516 can also be reached directly from step 510 via node 512 

20 in the case the object requested by the client 40 is already available. 

In step 516 the HTTP response including the requested object is ready to be sent to the 
client 40. This corresponds to the first step in the flow chart of Rg. 6 which will be dis- 
cussed below. 

25 

In principle, the redirection message (step 404 In Rg. 4) can be sent to the client 40 at 
any time while steps 502 to 516 are performed or after step 516. It should be noted that 
the availability of an object (I.e. whether a requested object is already cached, currently 
in transfer or whether the object is not requested yet) is a further factor that Influences 
30 the Initial priority of a requested object. 
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Re-ordering decisions 

Once the HTTP response is ready to be sent to the dient 40 (step 516 In Rg. 5), it has to 
be decided if an object comprised in the HTTP response should actually be delivered to 
the client 40, if the client 40 should be redirected or If the connection 50 via which this 
object is to be sent to the client 40 should be suspended. A flow chart depicting an ex- 
emplary decision scheme In this regard is depicted in Rg. 6. 

In step 602 the HTTP response is ready to be sent to the client. In the following step 604 
the priority of this object is evaluated with respect to the fact whether or not the priority 
has to be updated. If the priority of the object has to be updated, the priority is adjusted 
in step 604. 

In the next step 606 the current priority of the object is assessed to find out if it has the 
highest priority of all objects that are being transferred or that are expected soon. If it Is 
determined in step 606 that the requested object actually has the highest priority, the 
method moves via node 610 to step 612. In step 612 the requested object is sent to the 
client 40. 

If the comparison of the priority of the cun^ntly requested object with the priority of 
other objects in step 606 leads to the result that the cun-ently requested object does not 
have the highest priority, the method continues with step 614. With respect to step 606 it 
should be noted that Instead of comparing the priority of the currently requested object 
with the priorities of other objects It Is also possible to compare the priority of the cur- 
rently requested object with a fixed threshold or to add an offset In the comparison so 
that two priorities have to be different by more than a predefined threshold before the 
difference is considered significant enough. 

In step 614 the proxy server 30 estimates If the link 14 to the dient 40 (see Rg. 2) Is or 
will be Idle. As explained above, there are several ways to do that. One of them com- 
prises calculating a running average of the maximum amount of data that was sent and 
acloiowledged during the last N seconds over all connections 50 going to the same dient 
40. This gives an estimate of the maximum throughput available. 



wo 03/085924 



-22- 



PCT/EP02/03802 



The result thus obtained is then compared with the amount of data that is ready to be 
sent on the connections 50 that are not suspended. If the proxy sen/er 30 detects that it 
does not have enough data to send in order to fill the link during at least one complete 
round-trip time, then it considers that there is some spare bandwidth on the link 14 to- 
wards the client 40 and continues with stsp 616. 

In step 616 a comparison similar to that of step 606 Is performed. If it Is determined In 
step 616 that the currently requested object has a higher priority than all objects ex- 
pected soon, the proxy server 30 continues via node 610 with step 612 and sends the 
currently requested object immediately to the client 40. Otherwise the method continues 
with step 618 and a redirection message (status code "302") is sent to the client 40 as 
discussed above in conjunction with Fig. 4. 

The decision taken in step 616 can be influenced by the size of the cun-ently requested 
object (if it is already known). If the object is known to be small (e.g. less than twice the 
size of a redirection message), then the proxy server will always send the object instead 
of sending a redirection message, even if the object had been assigned a very low priority 
until then (this can be considered as one way of updating the priorit/). 

If it is detemilned in step 614 that there Is enough data to be sent in order to fill the link 
14, the method continues with step 620 and suspends the connection 50 to the client 40 
via which the cun-ently requested object is to be transferred. 

From either one of step 612, 618 and 620 the method continuous with step 622. In step 
622 the proxy server 30 re-evaluates all suspended connections 50 to find out whether 
any one of the suspended connections 50 are to be opened again. 

The HTTP/1.1 protocol supports the pipelining option, which allows the client 40 to send 
several requests to the server 20 or proxy server 30 on the same TCP connection without 
waiting for the previous replies. In the case pipelining is used, more than one object that 
is ready to be sent could be sent on the same connection 50 towards the client 40. It Is 
apparent that in such a case an object having a low priority could block a second object 
having a high priority that is to be sent on the same connection 50. If there are several 
objects waiting on the same connection 50, the maximum or average priority of these 
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objects may be determined and considered in steps 606 and 616. This ensures tiiat ob- 
jects of lower priority do not blocic objects of liiglier priority. 

Possible Extensions 

Several extensions, some of which have already briefly been discussed, to the exemplary 
embodiment described with reference to Rgs. 1 to 6 could be implemented. 

One of these extension relates to constraining the transfer speed on link 14 in depend- 
ence of the priority of the objects to be transferred. This could be done for example by 
allocating a specific share of processing capabilities to each connection 50 depending on 
the priority of the objects to be transferred. The priority of the individual objects is de- 
creased while the process is running. If the proxy server 30 processes connections 50 in a 
round-robin fashion, this feature can be implemented by limiting the amount of data 
transferred per round on each connection 50 by a number that is derived from the priority 
of that object. The dynamic allocation of processing capabilities can advantageously be 
combined with the suspension and redirection mechanisms discussed above. The process- 
ing capabilities can also include any transfomiation of the objects or codes being trans- 
ferred. 

According to a further extension of the invention, the priorities are assigned directiy by 
the browser running on the client 40. The browser can then schedule the HTTP requests 
for individual objects according to their priority. If the priorities are assigned directly by 
the browser, there are some additional factors that can be used for refining the priority of 
each object: 

position of the object in the page (coordinates) 

relative position of the visible area (oljjects that are outside the visible area 
have a lower priority) 

if image loading or script execution is disabled, the browser Icnows Immedi- 
ately that it is not necessary to assign a priority to these objects. 



wo 03/085924 



-24- 



PCT/EP02/03802 



Additionally, the browser knows when a user selects a new HTML page from the book- 
marks or by typing in a new URL. The browser can thus clear the list of objects that are 
no ionger required. 

A further extension of the invention relates to a proxy component that is located on the 
same computer (client) as the browser or close to this computer In terms of network 
links. This situation is depicted In Rg. 7. 

As becomes apparent from Rg. 1, the client 40 not only comprises a browser component 
42 but an additional proxy component 30 (having the structure shown in Rg. 3) in com- 
munication with the browser component 42. In such a case the link 14 between the proxy 
component 30 and the browser component 42 has a much higher capacity and lower la- 
tency than the link 12 between the proxy component and the server 20 (not depicted in 
Rg. 7). 

As a result, the client-side proxy component 30 influences the request stream because it 
cannot do much on the response stream. Based on the priority information derived from 
the current HTTP request and previous HTTP responses (e.g. previous HTI^L codes refer- 
ring to further objects) as well as an estimate of the link availability, the client-side proxy 
component 30 will decide if a HTTP request should be fbnwarded to the server and/or if it 
should reply Immediately with a redirection message. 

The decisions to be taken are simpler than depicted In the flow chart of Rg. 6. More par- 
ticularly, the decisions can be reduced to evaluating if the currently requested object has 
a lower priority than some of the objects being transferred or expected to be transferred 
soon and if the link Is already fully used. If both conditions are given, then a redirection 
message is sent to the browser component 42. In all other cases, the HTTP request is 
immediately forwarded to the server. 

If HTTP pipelining is used on a specific connection and If some previous HTTP requests 
are being processed, then the client-side proxy component 30 can suspend the HTTP re- 
quest until it can take the decision. It will have to take a decision at the latest when the 
previous objects have been fully received. 
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A Still further extension of the invention relates to the blocking of downloads for some 
objects based on tiieir priority. This means tiiat the priority tiiat is assigned to the objects 
can also be used to block the objects completely. If a threshold on tiie priority has been 
set, any object that has a priority that is lower than this threshold will not be sent to the 
client 40. In this case the proxy server (or proxy component) 30 would simply return one 
of the "4xx" or "Sxx" status codes defined in the HTTP/1.1 standard to the client 40 when 
it detects such an object. Possible status codes are "403 forbidden", "409 conflict" or 
"503 service unavailable". 

As an additional extension the priorities assigned to the objects could be used for pre- 
fetching. A pre-fetching mechanism allows the proxy server 30 to fill its buffer 36 (see 
Rg. 3) with some objects before the client 40 actually requests them. Such a pre-fetching 
mechanism may for example be based on the analysis of a HTML code that is sent from 
the proxy server 30 to the client 40 and that includes references to furi:her objects. Based 
on the analysis of the references to the objects the proxy component 30 assigns priorities 
to the individual objects and on the basis of this assignment it is defined which objects 
are to be pre-fetched and in what order. Preferably, the objects are pre-fetched starting 
with the objects having the highest priority. 

According to a still furiiher extension that may be combined with the pre-fetching mecha- 
nism discussed atrave, specific pushing schemes are implemented that allow to transfer 
objects from the proxy server 30 to the client 40 without having received an explicit ob- 
ject request from the client 40. 

Various modifications of the preferred embodiment are possible without departing from 
the scope and spirit of the present invention. Although the invention has been described 
in connection with a preferred embodiment. It is to be understood that this description is 
not intended to limit the invention tiiereto. Rather, the invention is intended to cover all 
modifications and/or additions to the above-mentioned description, without departing 
from the spirit and the scope of the invention. 
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CLAIMS 

1. A method of controlling In a communications network (10) an object trans- 
fer frxjm a first component (20) via an Intennedlate component (30) to a 
second component (40) which is remote from the first component (20), 
wherein the object transfer is based on a plurality of object requests relat- 
ing to objects referred to in one or more c»des to be processed by the sec- 
ond (40) or another component of the communications network (10), the 
intermediate component performing the steps of: 

sending an object request to the first component (20); 
receiving the requested object from the first component (20); 
assessing and/or updating a priority of the requested object, 
wherein an initial priority has been assigned to the requested object 
on the basis of an analysis of at least one of the object request and 
the code that refers to the requested object; and 
In dependence of the priority of the requested object, delaying the 
requested object or forwarding the requested object to the second 
component (40). 

2. The method of claim 1, 

wherein the delaying is performed such that the order In which the objects 
are received from the first component (20) differs from the order in which 
the objects are forwarded to the second component (40). 



30 



3. 



The method of claim 1 or 2, 

wherein the object request is received from the second component (40) or 
generated by the intermediate component (30). 
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4. The method of one of daims 1 to 3, 

wherein delaying of the requested object includes at least one of instruct- 
ing the second component (20) to repeat the object request, suspending a 
connection to the second component (40) via which the requested object is 
to be fonwarded, and informing the second component (40) that the re- 
quested object will automatically be fonwarded at a later point in time. 



5. The method of claim 3, 

wherein instructing the second component (40) to repeat the object 
10 request includes: 

assigning a specific attribute to the object to be delayed; 
informing the second component (40) of the attributes- 
receiving a reference to the attribute from the second component 
(40); and 

15 - upon receipt of the reference to the attribute, sending the delayed 

object to the second component (40) or further delaying the de- 
layed object. 

6. The method of one of one of claims 1 to 5, 

20 wherein requested objects are forwarded to the second component (40) via 

a plurality of connections (50) to the second component (40). 



7. The method of claim 6, 

wherein selected ones of the connections (50) to the second component 
(40) are suspended dependent upon the priorities of the requested objects 
that were received from the first component (20) and that are to be for- 
warded via the selected ones of the connections (50). 



30 



8. 



The method of 6 or 7, 

wherein to each connection a specific share of processing capabilities Is dy 
namically allocated. 
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9. The method of one of daims 1 tx) 8, 
further comprising: 

sending a code request to the first (20) or a third component; 
receiving the requested code from the first (20) or the third compo- 
5 nent; 

analyzing the received code with respect to references to objects; 
assessing the references to objects with the purpose of assigning 
initial priorities to the objects referred to In the received code. 

10 10. The method of one of claims 1 to 9, 

wherein upon receipt of a response containing the object requested from 
the first component (20), the response is evaluated witli respect to the re- 
ceived object's priority in order to determine whether or not the initial 
priority of the received object has to be updated. 

15 

11. The method of one of claims 1 to 10, 

further comprising generating a priority list tiiat contains priority informa- 
tion for individual objects or classes of objects. 



20 12. The method of daim 11, 

fijrt:her comprising repeatedly assessing the priority list with respect to at 
least one of updating priority information and deleting objects or dasses of 
objects, or corresponding information, from the priority list. 



25 13. The method of one of daims 1 to 12, 

wherein the steps are peri'omied by a proxy component situated on the 
first component, on the second component or configured as a separate 
hardware component (30) of the communications network. 
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14. A method of delaying in a communications networic (10) an object transfer 
from a first component (20) via an intermediate component (30) to a sec- 
ond component (40) wliich is remote from the first component (20), 
wherein the object transfer is based on a plurality of object requests relat- 
ing to objects refen-ed to in one or more codes to be processed by the sec- 
ond (40) or another component of the communications network, the inter- 
mediate component (30) performing the steps of: 

assigning a specific attribute to an object which is to be delayed; 
informing the second component (40) about the attribute; 
receiving a reference to the attribute from the second component 
(40); and 

upon receipt of the reference to the attribute, sending the delayed 
object to which tiie attribute has been assigned to the second com- 
ponent (40) or further delaying the delayed object. 

15. The method of claim 14, 

wherein the object is sent to the second component (40) in accordance 
witin a pushing scheme or in response to an object request received from 
the second component (40). 

20 

16. The method of claim 15 

wherein the second component (40) is informed about the attribute In con- 
text with an Instruction to repeat the object request and wherein the refer- 
ence to the attribute is received from the second component (40) in con- 
25 text with a repeated object request. 

17. A computer program product comprising program code portions for per- 
forming the steps of claims 1 to 16 when the computer program product is 
run on a computer system (30). 

30 

18. The computer program product of claim 17, stored on a computer readable 
recording medium. 
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19. An intermediate component (30) for controlling in a communications net- 
work (10) an object transfer from a first component (20) via the intermedi- 
ate component (30) to a second component (40) whicti is remote from tlie 
first component (20), wherein the object transfer is based on a plurality of 
object requests relating to objects referred to in one or more codes to be 
processed by the second or another component of the communications 
networic, the intermediate component (30) comprising a communications 
interface (32) for sending an object request to the first component (20) 
and for receiving the requested object from the first component (20), a 
processing unit (34) for assessing and/or updating a priority of the re- 
quested object, wherein an initial priority has been assigned to the re- 
quested object on the basis of an analysis of at least one of the object re- 
quest and the code that refers to the requested object, and wherein the 
processing unit (34) in dependence of the priority of the requested object 
delays the requested object or controls the communications interface (32) 
to fonward the requested object to the second component (40). 

20. An intermediate component (30) for delaying in a communications networl< 
(10) an object transfer from a first component (20) via the intermediate 
component (30) to a second component (10) which is remote from the first 
component (20), wherein the object transfer Is based on a plurality of ob- 
ject requests relating to objects referred to in one or more codes to be 
processed by the second or another component of the communication net- 
worl<, the intemiediate component (30) comprising a processing unit (34) 
for assigning a specific attribute to an object which is to be delayed and a 
communications interface (32) for informing the second component (40) 
about the atb:ibute, for receiving a reference to the attribute fix»m the sec- 
ond component (40) and, upon receipt of the reference to the attribute, for 
sending the delayed object to which the attribute has been assigned to the 
second component (40) or further delaying the delayed object. 



10 



wo 03/085924 PCT/EP02/03802 

-31- 



21. The intermediate component of claim 19 or 20, configured as a proxy 
server (30). 

22. A networic system (10) comprising at least one of the components (30) of 
claims 19 to 21. 

23. The network system of claim 22, further comprising a first link (12) be- 
tween the intermediate component (30) and the first component (20) and 
a second link (14) between the Intemiediate component (30) and the sec- 
ond component (40), wherein the first link (12) and the second link (14) 
have different transfer rates. 

24. The network system of claim 22 or 23, comprising a second component 
(40) in the form of a mobile terminal. 



15 
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